Skip to content

Conversation

jcpunk
Copy link
Contributor

@jcpunk jcpunk commented Jul 16, 2025

Leaving cmake 2.8 may have some long term cost, but for now it all works as expected.

External projects will need to manage their own cmake_minimum_required.

Fixes: #1248

@johnbartholomew
Copy link
Collaborator

Leaving cmake 2.8 may have some long term cost

Given how old CMake 2.8 is, and the significant changes with CMake 3, I would be open to a PR that brings the minimum supported version up to at least 3.5 and possibly something newer (I think 3.5 was released in 2016?). If possible, I would like it to still build on at least the oldest still supported (including LTS support) Debian release (*). At some point the code started to require C++17 so it doesn't seem useful to support a CMake significantly older than the oldest version of GCC that would be able to build it; that might be GCC 9 (https://gcc.gnu.org/gcc-9/changes.html has "The C++17 implementation is no longer experimental." - though experimental C++17 support was available since earlier versions). GCC 9.1 was released in 2019.

(*) Not because Debian is special, but because it's a useful reference point for a likely "old but still in-use version", and it's fairly easy to find what version is available in that distro.

Leaving cmake 2.8 may have some long term cost, but for now
it all works as expected.

External projects will need to manage their own cmake_minimum_required.

Signed-off-by: Pat Riehecky <[email protected]>
@johnbartholomew johnbartholomew merged commit 6c87c1b into google:master Jul 22, 2025
7 checks passed
@jcpunk jcpunk deleted the cmake4 branch July 22, 2025 13:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CMake 4 support
2 participants